<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Upgrade plan',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/07/24.jpg" alt="Construction downtown continues as well" class="framed-centred-image" width="649" height="480"/>
<section id="Minetest">
	<h2>Minetest</h2>
	<p>
		I haven&apos;t done any work on the code today, but while thinking through how to make my dye system work, I came to the realisation that I have no source for three of the eight basic dyes I need.
		The <code>dye</code> mod gets them through colour-mixing that doesn&apos;t make sense, but my mod&apos;ll need all eight basic colours to be available <strong>*before*</strong> mixing.
		After all, these are the extreme dyes.
		My system uses colour averaging, so the extreme dyes can&apos;t be gotten through mixing.
		I&apos;ll need to define some new recipes for dye acquisition.
	</p>
	<p>
		I&apos;m still not sure about what to do about magenta dye.
		At first, I figured I could boil down cacti for green dye and maybe craft cyan dye out of jungle grass.
		I really didn&apos;t like the idea of wasting jungle grass like this though.
		I&apos;d rather use jungle grass for seed-gathering.
		That&apos;s when it hit me: when jungle grass drops seeds, what happens to the rest of the grass plant?
		It could drop cyan dye along with the seeds!
		I could have the tallest grass variant drop green dye along with its seeds too, eliminating the need to boil down cacti.
	</p>
	<p>
		As an awesome bonus, this plan would allow <code>minestats</code> to track the gathering of these two colours of dye.
		However, <code>minestats</code>, in its current form, would track these both as generic dye, which would display on the stat page as white dye.
		Technically, all dies in my mod will be the same item with different data associated with them.
		<code>minestats</code> doesn&apos;t currently distinguish.
		I guess it&apos;s time to upgrade <code>minestats</code> again.
	</p>
	<p>
		I guessed these are the things I, at a minimum, wanted to add to the new <code>minestats</code> version:
	</p>
	<ul>
		<li>
			support for items and nodes coloured with a palette index
		</li>
		<li>
			support for items coloured with a colour string
		</li>
		<li>
			support for per-stack descriptions
		</li>
		<li>
			detection to prevent tool stacking
		</li>
		<li>
			support for tool wear
		</li>
	</ul>
	<p>
		At first, I thought I&apos;d add support for all item (but not node) meta data.
		And at this stage, I was still open to the idea that perhaps I still would.
		However, it&apos;s worth noting that most item meta data isn&apos;t visible to the user in any way.
		The palette index and colour string aren&apos;t directly visible, but they do alter the appearance of the stack visibly.
		As for tool stacking, Minetest doesn&apos;t allow tools to be stacked, but <code>minestats</code> attempts to stack them anyway.
		Then, it uses Minetest&apos;s capabilities to normalise the stack, which probably causes the quantity to be lost, condensing the tools into a single tool for counting.
		It&apos;d be better to just count these as multiple tool drops.
	</p>
	<p>
		By the end of the day, I&apos;d managed to codify the behaviour I&apos;d give <code>minestats</code>, and in so doing, justify what I wanted from it.
		I find that on important projects, if I can&apos;t codify the behaviour I want into a simple concept, I&apos;m doing it wrong and I&apos;ll need to go back and majorly fix things later, once I have a better idea of what the proper behaviour is.
		Auxiliary projects can have as many bizarre quirks as they need to and still come out mostly fine, but the important projects they depend on need to be very specific and simple.
		The code and implementation may not always be simple, but the underlying behaviour absolutely must be.
		Anyway, what I came up with is all about expected verses actual drop stacks.
		Without defined drop data, what would the node drop?
		This question allows us to add in the <code>param2</code> data, but only in the case of coloured nodes, and in the case of nodes that pack more than just colour into their <code>param2</code> data, only colour is preserved.
		This is <strong>*exactly*</strong> the behaviour we need for distinguishing different colours of nodes without taking into account stupid things such as a node&apos;s facing direction.
		It also allows us to justify not even considering a node&apos;s <code>param1</code> data, which usually is used for something irrelevant to <code>minestats</code>, such as lighting level.
		The <strong>*only*</strong> new node-related support I want to add right now is in regards to colour.
		Going forward, this will also help me decide what new features I should support if and when Minetest adds something I&apos;m considering doing something with.
		I&apos;ll need to follow this maxim or find a new justifiable one.
		Second, we have a question for actual dropped stacks.
		After condensing where allowed by the engine and without irreversibly altering the stacks and losing data, what stacks were dropped?
		This allows us to fix the tool-stacking issue, as the engine deletes the quantity data when you attempt to stack tools.
		It also allows us to take into account colour information.
		In fact, this question demands that we take <strong>*all*</strong> drop item metadata into account.
		While taking into account all node metadata is intuitively wrong (For example, it&apos;d require us to count leaves in sunlight as a different node than leaves in a cave. Likewise, it&apos;d require counting freshly-grown leaves as a separate node than player-placed leaves. Furthermore, locked chests placed by different players would be considered different nodes.), taking into account all metadata from the drop is just fine, and in fact could be useful later.
		Why would the drop stack even <strong>*have*</strong> metadata if it didn&apos;t matter?
		This new behaviour will also allow the tool wear of dropped tools to be displayed in the stats menu, should a node drop a tool for some reason.
		Finally, this new design plan justifies something I&apos;d already coded into <code>minestats</code> from the beginning: stacking of drops above their natural limit, up to the limit supported by the engine.
	</p>
</section>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion posts for the day:
	</p>
	<blockquote>
		<p>
			I agree with you on all points but one.
			Jim&apos;s not the one choosing whether or not to turn someone in.
			Finn&apos;s the one making the decision, so it&apos;s Finn&apos;s morals that need to be taken into account, not Jim&apos;s.
			Finn doesn&apos;t need to look at what Jim would do toward another slave as much as what he would want others to do, were Finn himself a runaway slave.
			If Finn thinks runaway slaves should be turned in, he should think he himself should be turned in had he been a runaway slave.
			However, if Finn thinks runaway slaves shouldn&apos;t be turned in, then he likewise shouldn&apos;t turn in Jim.
		</p>
	</blockquote>
	<blockquote>
		<p>
			That&apos;s exactly my point.
			Finn put the food back to make himself feel better, but feeling better is unjustified based on what he actually did.
			He wasted food.
			Clearly, he didn&apos;t actually think things through.
		</p>
	</blockquote>
	<blockquote>
		<p>
			I think you misunderstood a bit.
			Creating life isn&apos;t a categorical imperative for me.
			<strong>*Not*</strong> creating life is the categorical imperative.
			I do have control over it.
			There are medical procedures one can have performed on oneself to make one no longer fertile, and before I would ever have sex with someone of the opposite sex, I would undergo such an operation.
			It&apos;s fully within my ability to choose.
			If I can&apos;t afford the operation, I don&apos;t pair up with someone of the opposite sex, even if that means being alone.
			That said, I&apos;m more interested in a same-sex relationship anyway, so I don&apos;t have that problem to deal with.
		</p>
		<p>
			As for gods, I don&apos;t believe in them.
			I believe we make our own decisions and aren&apos;t subject to a metaphysical overlord that runs our lives for us.
		</p>
	</blockquote>
	<blockquote>
		<p>
			Okay, you&apos;re saying that categorical imperatives aren&apos;t culture-specific, but there are a couple problems with that.
			First, look at the discussion question.
			You wrote to provide an example <strong>*from our lives or cultures*</strong>.
			If they&apos;re not culture-specific, the discussion question makes no sense.
			Second, morality is highly subjective.
			Everyone has their own take on it.
			As far as I know, there doesn&apos;t exist even a single categorical imperative that everyone can agree on.
			If categorical imperatives are not specific to the people that follow them, there simply cannot be any categorical imperatives.
			They simply cannot exist universally.
			They can only be <strong>*applied*</strong> universally by a <strong>*specific*</strong> person or culture.
		</p>
	</blockquote>
	<blockquote>
		<p>
			I do wonder if Finn actually plans to repay any of the stuff he stole, and if so, if he&apos;ll actually remember to follow through.
			I mean, he&apos;s a runaway child with no home and, as far as I can tell, no future.
			He and his friend Jim will very likely survive well enough, but neither is likely to end up in a position in which they have something to give back to the farms they stole from.
			Plus, the two of them are fleeing.
			Are they ever going to be near these farms again to repay their debt?
		</p>
	</blockquote>
	<blockquote>
		<p>
			I agree one shouldn&apos;t break promises, but with one small addendum: promises made under duress are null and void.
			For example, my mother, who divorced my father, threatened my brother, telling him she&apos;s kick him out of the house if he didn&apos;t promise never to see our father again.
			Of course, my brother had nowhere to go at the time, and wasn&apos;t yet an adult.
			He had to promise.
			There was no choice.
			Our mother would be in the wrong for even <strong>*asking*</strong> him to make such a promise, but to put his living situation on the line was completely out of line.
			Later, after my brother moved out, he of course broke that promise.
			He visits our father every once in a while.
			I feel it&apos;s perfectly fine for him to do so.
			<strong>His promise didn&apos;t count because he was coerced into making it.</strong>
		</p>
		<p>
			Our mother disowned him over that &quot;broken promise&quot; though.
			Ironically, of my mother&apos;s four children, my brother&apos;s the only one planning on having children of his own.
			My mother wants grandchildren, but if she ever expects to meet any of her grandchildren, she&apos;s going to have to make up with her only son, my brother.
		</p>
	</blockquote>
</section>
END
);
